Failures of this test made me update other tests in this PR. I have to force event loop to make a single turn to catch this as unhandled promise rejection.

I have to force event loop to make one turn at least when there is an unhandled rejection processed before. Otherwise, this test would be still failing because rejectionHandled needs one event loop turn to be processed. I could make this when there is at least one unhandled rejection before to not modify tests mentioned in the previous comment. However, I would hide those consequences only. Those cases can still happen IMO in situations like this one.

Are 0 still detected? If not, we should try to set some other flag so we can detect this case immediately after tests are done

Yes, they are detected. That is why I had to update this test (and the other one as well).

If it's still detected I'm not 100% sure why this had to change? Is the error just different?

Oh, I miss-understood originally. Unfortunately 0 are not detected after my changes. Possibly even 1 or other small count if ms are not detected. It is cased by the extra event loop turnaround I need to ensure detection of handled and unhandled rejections.

Let me think a bit about the possible solution.

I took a deep loop into both cases (jest environment method access after teardown and late require) and both seems fragile already.

1. Any async event handler can break it. No matter what the even handler would do, anytime it takes at least one even-loop turnaround, this gets broken. More even-loop turnarounds in an async event handler, the more "suppressed" errors like this. Both errors are thrown on runtime level when the circus is out of game already. The runtime assumes the the time between a test and tearing runtime down is strictly sync (which may not be).
2. "jest environment method access after teardown" validates a single timers method access only. All other Jest environment methods usages are not reported at all, even on the current main branch.

I introduced the first truly async event handler. Therefore, the detection has changed because of the first point.

I was thinking about a new flag, however, I would need to make a hard choice as a user between the following variants:

A)

• I can keep the current behaviour detecting late require as well as late global method usage.
• I won't be able to detect unhandled rejections when the promise rejection happens in the same event loop turn as the test ends.
• I would still get false failures for unhandled rejections when the rejected promise handling happens in the same event loop turn as the test ends.
• I would still get global unhandled rejection error in case there is a floating promise being rejected way after its creation (e.g. when tearing down the env).

B)

• I get all promise rejections error accurately (except rejections happening way after the promise creation).
• I won't get reported on late requires nor late global method usage when it happens within the same event loop turn as the test ends (as it is still considered as part of the test).

I would prefer variant B) as you would probably guess. What is the reasoning behind those checks though?

I think there is a variant C) though. It would mean those 2 specific conditions get changed so they are detect on circus level rather than on runtime level. However, I am not sure how feasible that.

I was also thinking about variant D) - capturing all pending timers, leaving there the one waiting for the next even loop turn and the reapply the remaining timers. However, it feels hacky and I was not able to think of a way for other envs than Node.js (and even that is questionable).

Thanks for digging! I think your change is fine considering the tradeoffs.

I guess what we could do was signalling from Circus that we are done running tests once the teardown event fires, at which point the runtime would start rejecting new requires etc. even though it hasn't started its own teardown. Might not really be feasible in the current architecture, tho?

I actually got the same idea in the evening but I did not have time to look into it yet 😃 I will give it a shot

I believe I have the solution.

I am using value undefined as a sign that no test started yet so Jest can still use requires of modules prior running the test module (e.g. requiring the test module itself).

I am open for suggestions about wording of both kinds of errors.